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Purpose 


To  introduce  a  set  of  guidelines  for  dealing  with  systems  of  systems 
programmatics,  and  show  how  these  can  aid  in  the  identification  and 
resolution  of  issues. 
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Background 


What  is  the  vision  for  net-centric  operations? 


Bottom  line:  Seamless,  ubiquitous  interoperability  enabling  dynamically- 
composable  capabilities  to  achieve  desired  mission  effects 
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Backgrounds 


Current  approaches  to  providing 
capability  based  on  integration  of  and 
interoperation  between  systems 

•  Constituent  systems  not  necessarily 
developed  with  “broad” 
interoperability  in  mind 

•  Acquisition  (development, 
sustainment,  etc.)  focused  on  their 
individual  systems/programs,  with 
their  individual  requirements,  funding, 
users,  etc. 

•  Integration  “after  the  fact” 


UA  Battlespace 


MILSATCOM 


sncli* 


PCS  CorfTpnftn  enter 
Syitem  i 

UAOomplem  enter;, 


UE  Si.  Above  Complem  enter; 
Syitemi 


New/F^opoied 
S  ‘item  i 


Future  Combat  Systems 

Defining  Program  Relationships 


FCS  Core  Sterns:  19 
systems  identified  in 
FCS  ORO,  Annex  A.  D 
&  E 


FCS  Complementary 
Systems:  Systems 
essential  for  family  of 
systems  interoperability 
not  in  FCS  Core.  Systems 
have  applicability  outside 
FCS  Core  Systems. 

UA  Complementary: 
Systems  needed  to 
support  system  of 
systems  operations  Uhit 
set  fi  el  ding  i  mpli  cati  ons. 


U  E  &  Abo  v*  Com  plem  entory: 

S  yitem  i  ne  edeO  to  operate  or 
■upporta  i ;  item  ot  lyit.m  i 
outline  tile  U  A  \ 
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Example  from  “Future  Combat  Systems 
Program  Relationships” 
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Backgrounds 


Results  in  disconnects  between  the  goals  and  reality: 

Goal  Reality 


•  Seamless  interoperability 


•  Dynamic,  flexible,  responsive  to 
changing  environment  and  threat, 
survivable 

•  Programs  will  “cooperate  and 
graduate” 


•  Interoperability  either  insufficiently 
defined  (e.g.,  “interoperable  with  XYZ 
system”)  or  too  narrowly  constrained 
(e.g.,  “interoperable  with  XYZ 
system,  using  TDMA  over  25  KHz 
UHF  DAMA  STACOM  ...”  etc. 

•  Integration  results  in  brittle  systems 
that  are  fragile  and  difficult  to  sustain 


•  Stovepiped  programs/systems  not 
incentivized  to  engage  in  altruistic 
behavior 
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Background 


For  many  reasons,  systems  of  systems  are  currently  the  preferred  approach  to 
providing  net-centric  capabilities 

Certain  inescapable  consequences  of  systems  of  systems: 

•  Autonomous  constituents  with  independent  operations  and  management 

—  Includes  people,  organizations,  software  agents,  etc. 

—  Source  of  independent  actions  and  decisions 

•  Independent  operation/evolution  of  each  constituent 

—  Can  respond  to  new  technology  and  mission  needs  at  its  own  pace  and 
direction 

•  Emergent  behavior 

—  “Whole  is  different  than  the  sum  of  the  parts” 

—  Indirect  and  cumulative  effects  of  influences,  actions,  interactions 

These  require  a  fundamentally  new  approach  to  understanding  and  managing 
the  programmatics  (i.e.,  the  interrelationships  between  issues/decisions  in 
management,  development,  and  operations) 
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Backgrounds 


Some  critical  aspects  of  desirable  systems  of  systems  programmatics  include: 

•  Collective,  collaborative  behavior  to  accomplish  systems  of  systems  goals 

•  Understanding  the  interrelationships  and  interdependencies  between 
management,  development,  and  operational  domains 

•  Distributed  execution  authority 

•  Effective  decision  making  in  the  presence  of  inconsistent,  incomplete,  and 
incorrect  information 

These  often  conflict  with  the  “system-centric”  pressures  on  a  program  manager 
to  satisfy  their  instant  cost,  schedule,  and  performance  requirements 

What  is  needed  are  some  guidelines  to  help  program  managers  in  the 
execution  of  their  responsibilities  consistent  with  systems  of  systems 
principles:  the  “ Laws  of  Programmatics” 
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The  “Laws  of  Programmatics” 


Zeroth  Law 

An  actor  or  constituent  (hereinafter  referred-to  as  actor)  shall  not  take  unilateral  action 
within  their  program  to  the  detriment  a  system  of  systems,  or  through  inaction,  knowingly 

allow  detriment  to  come  to  a  system  of  systems 

First  Law 

An  actor  shall  not  take  unilateral  action  within  their  program  to  the  detriment  of  another 
program,  or  through  inaction,  knowingly  allow  detriment  to  come  to  another  program. 

Second  Law 

An  actor  shall  comply  with  all  applicable  laws,  regulations,  directives,  policies,  etc.  issued 
by  competent  authority  except  when  doing  so  would  conflict  with  the  zeroeth  or  first  laws. 

Third  Law 

An  actor  shall  take  corrective  actions  to  remedy  any  risks,  issues,  problems  etc.  in  their 
program  except  when  such  actions  conflict  with  any  higher  law. 

Fourth  Law 

An  actor  may  “be  creative”  as  long  as  their  actions  do  not  conflict  with  any  higher  law. 
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The  Laws  in  Action 
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Zeroth  Law 


An  actor  shall  not  take  unilateral  action  within  their  program  to  the 
detriment  a  system  of  systems,  or  through  inaction,  knowingly  allow 
detriment  to  come  to  a  system  of  systems 

Applies  when  it  is  known  (or  can  reasonably  be  inferred)  that  a 
program  is  part  of  one  or  more  systems  of  systems 

Obligates  a  program  to  not  take  action  to  the  detriment  of  the  system(s) 
of  systems  in  the  pursuit  of  its  goals.  For  example: 

•  Capability  “X4”  is  critical  for  the  system  of  systems,  but  not  for  the 
success  of  program  “X” 

•  Program  “X”  should  not,  therefore,  decide  to  delete  capability  “X4”  on  its 
own,  even  when  it  has  the  authority  to  do  so  under  existing  acquisition 
program  guidance,  etc. 
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Zeroth  Law 


To  comply  with  the  zeroth  law,  several 
actions  need  to  be  undertaken: 


•  Program  “F’  must  explore  options  to 
prolong  its  operation  in  the  event  that 
system  “/\r”  cannot  be  ready  on  time 

•  Before  any  additional  changes  to 
systems  “F’  and  “F,”  program  “ A ”  must 
be  allowed  to  weigh  in  on  the  decision, 
and  suggest  possible  alternatives  that 
won’t  further  endanger  their  ability  to 
meet  schedule 

•  Program  “/A”  must  reconsider  their  risk 
reduction  effort  (system  “ A2 ”)  if  it  will  be 
unable  to  support  the  system  of 
systems  interoperability  requirements. 
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Law 


An  actor  shall  not  take  unilateral  action  within  their  program  to  the 
detriment  of  another  program,  or  through  inaction,  knowingly  allow 
detriment  to  come  to  another  program. 

Obligates  a  program  to  not  take  action  to  the  detriment  of  another 
program.  For  example: 

♦  Program  “V”  has  an  interoperability  requirement  with  program  “ X'\  this 
interoperability  is  critical  to  the  success  of  program  “X,”  but  not  for 
program  “V” 

•  Program  “Y’  should  not  remove  or  modify  this  requirement  on  its  own 
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Law 


Independent  program  actions  causing 
harm  to  other  programs: 


Changes  to  system  P  require 
corresponding  changes  to  system  B 

—  Impacts  design/development  for 
system  A1 

System  A  risk-reduction  effort  (A2) 
will  impose  significant  changes  on 
system  B  if  implemented 
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Second  Law 


An  actor  shall  comply  with  all  applicable  laws,  regulations,  directives,  policies, 
etc.  issued  by  competent  authority  except  when  doing  so  would  conflict  with 
the  zeroth  or  first  laws. 

This  obligates  a  program  to  follow  the  applicable  laws,  directives,  etc.  unless 
doing  so  would  harm  another  program  or  the  system(s)  of  systems 

One  consequence  of  this  is  to  require  that  a  program  “throw  an  exception” 
when  there  are  conflicts  between  the  laws,  directives,  etc.  and  the  needs  of 
another  program,  or  the  system(s)  of  systems.  For  example: 

•  Funding  for  program  “X'  is  reduced,  which  will  result  in  a  delay  to  fielding  a 
capability  that  is  critical  to  the  system  of  systems 

•  Program  “X”  should  identify  the  conflict  between  its  goals  and  those  of  the 
system  of  systems,  and  attempt  to  find  a  solution  (or  force  reconsideration) 
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Second  Law 


Conflict  between  goals,  directives,  etc. 
of  individual  programs  and  the  system 
of  systems: 

•  Planned  retirement  of  system  P 
jeopardizes  system  of  systems 

—  What  if  system  A1  not  ready? 

—  What  if  program  A  risk 
reduction  effort  (system  A2)  is 
implemented? 
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Third  Law 


An  actor  shall  take  corrective  actions  to  remedy  any  risks,  issues, 
problems  etc.  in  their  program  except  when  such  actions  conflict  with 
any  higher  law. 

This  obligates  a  program  to  not  take  actions  to  the  detriment  of  the 
system(s)  of  systems  or  other  programs,  or  violate  applicable  laws, 
directives,  etc.  while  mitigating  their  own  problems 

As  an  example: 

•  Program  “V”  has  a  backwards  compatibility  requirement  with  program 
“ X and  is  experiencing  significant  cost  and  schedule  pressures  that 
can  be  ameliorated  by  deferring  this  capability 

•  Program  “V”  should  not  defer  this  capability  on  its  own 
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Third  Law 


Conflict  between  risk  reduction  efforts 
or  mitigation  strategies  of  individual 
programs  versus  systems  of  systems 
capabilities: 

•  System  A1  risk  reduction  effort  (A2) 
satisfies  system  A1  requirements, 
but  adversely  impacts  system  B  and 
broader  system  of  systems 
requirements 

•  Is  there  a  minimally-acceptable 
subset  of  interoperability  that 
system  A2  could  provide  that  would 
preserve  system  of  systems  goals? 
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Fourth  Law 


An  actor  may  “be  creative”  as  long  as  their  actions  do  not  conflict  with 
any  higher  law. 

While  in  the  context  of  a  single  program,  there  may  be  numerous 
examples  of  effective  solutions  to  questions  about  organizational 
issues,  risk  management,  budgeting,  etc., 

The  same  is  not  true  for  systems  of  system:  most  of  what  program 
managers  have  learned  through  their  experiences  and  training  leave 
them  ill-prepared  to  deal  with  the  uncertainties  of  systems  of  systems 

•  Since  there  are  no  “off-the-shelf”  solutions,  you  should  explore  some 
“out  of  the  box”  possibilities 


Systems-of-Systems  Programmatics: 

-  Software  Engineering  Institute 

Carnegie  Mellon 

Guidelines  for  Program  Managers 

Smith,  Meyers,  Fisher  -  June  21 , 2007 

20 

©2007  Carnegie  Mellon  University 

Fourth  Law 


When  there  are  no  known  “tried  and 
true”  solutions,  then  try  something  else! 


Keeping  your  “head  down,”  or  your 
“nose  to  the  grindstone”  won’t  make 
these  problems  go  away 

Programs  must  consider  the 
impacts  of  their  decisions  on  every 
other  program — and  on  the  system 
of  systems 

Programs  need  consider  this 
unpleasant  truth:  sometimes  the 
right  answer  is  “no” 
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Conclusions 


Systems  of  systems  are  the  preferred  approach  to  provide  net-centric 
capability 

Managing  a  program — and  maintaining  cost,  schedule,  and 
performance — has  never  been  easy,  and  systems  of  systems  bring 
many  new  challenges 

♦  Conflicts  between  system-centric  and  systems  of  systems  perspectives 

A  way  to  identify  these  conflicts,  and  provide  program  managers  with 
guidance  on  how  to  proceed,  would  help 

•  The  “laws”  are  an  attempt  to  provide  this 
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Future  Directions 


As  interesting  as  the  natural  language  representation  of  the  laws  may 
be,  a  formal  definition  is  required 

•  Currently,  working  on  a  formal  definition  that  integrates  Deontic  logics 
with  precedent-based  reasoning 

•  Desire  a  method  for  analyzing — and  recommending  courses  of  action — 
for  conflicting  normative  obligations 

Part  of  a  long-term  effort  to  be  able  to  identify  what  organizational 
architecture(s)  work  better  than  others,  under  what  conditions 

•  Goal  is  to  be  able  to  model  the  eigenbehaviors  of  organizations, 
defined  by  their  “genomes,”  operating  within  a  framework  defined  by 
the  laws,  when  confronted  by  various  systems  of  systems  issues 
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